[レポート] Docker と Amazon ECS で DevOps を進化させる #AWSSummit

Docker と Amazon ECS で DevOps を進化させる

6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 の Develoeprs Confrence のセッション「Docker と Amazon ECS で DevOps を進化させる」を聴講しました。本記事はそのレポートです。

コンテナ技術である Docker と、Amazon EC2 のクラスタ上でコンテナを管理できる Amazon EC2 Container Service (ECS) を利用することで、アプリケーションとインフラという2つの密結合したライフサイクルの管理から脱出し、新しい DevOps へと向かう方法、及びその事例をいくつかご紹介します。

スピーカーは 岩永 亮介 氏（アマゾン ウェブ サービス ジャパン株式会社　技術本部 メディア・エンターテインメント部 ソリューションアーキテクト）です。

セッション

自己紹介

• メディア・エンターテインメント部 ソリューションアーキテクト
• AWS を使ってる人や使おうとしている人への技術的課題解決を担当している

質問

どのような層が参加者か、簡単なアンケートがありました。

• インフラ : 1/4 くらい
• アプリ : 1/3 くらい
• Docker : 1/6 くらい
• ECS : ごく少数

DevCon だけあって、アプリケーションエンジニアが多めです。

DevOps とは？

• いろんな言い方ができるが、このセッションでの DevOps とは…
• 開発のライフサイクルは、下記のループ回す
• 開発して
• ビルドして
• テストして
• リリースして
• どういう行動、KIPか調べて
• またデリバリする
• これを、いかに早く回すか。お客様に価値を届けるか

モノリシックな開発サイクル

• 問題点はアプリが大きくなりがち、デプロイに時間がかかりがち
• Amazon も同じ課題を抱えていた。
• すごくテストがかかってた
• マイクロサービスに分割
• チームも分割
• 2ピザで運用する(ピザ2枚が足りるくらいの人数のこと、5~8人くらい、詳しくはこちら)
• デリバリーの速度を上げる

モノリシックとマイクロサービス

• モノリシックの場合は
• UI、裏ロジック、アクセス方法全部1つのコンポーネント
• スケールする場合は全部合わせて
• マイクロサービスの場合は
• 個別に展開される
• 個別にスケールする
• UIは台数いらないから少なめとか、ここはアクセス多いからいっぱいとか
• 効率的
• デリバリーごとにパイプラインが生まれる
• それぞれのコンポーネントで高速に価値を届ける
• マイクロサービスは必要としてないから聞かない、というわけじゃない
• 新規事業とかあるし、サービス分かれるし、サービスが自然と多くなる
• それぞれに高速化しないといけなくなる

4つのフェーズ

• ソース
• ソースコードを書く
• コンパイル
• 簡単なチェック
• テスト
• インテグレーションテスト
• 負荷テスト
• UI テスト
• 心理テスト
• プロダクション
• 本番にデプロイ

DevOps の実態

• 手元で開発 -> ビルド、テストをする -> プロダクションに撒く
• プログラムを書けばいけばいいだけでにしたいのに、やらないといけないことがいっぱい
• 環境ごとに Vagrant とか
• それぞれにちゃんとプロビジョニング(Chef とか)
• スケール
• 障害対応
• パイプラインが増える
• 言語、バージョン、フレームワーク
• 1人が守る
• スパゲッティになっていく (複雑化)

DevOps の難しさ

• Dev と Ops を組み合わせると、ユニコーンな人、チームが必要になる
• なかなか管理しきれない

Docker

• モデルがシンプル
• アプリそのものがモデル
• シンプルなモデル (イメージ)
• バージョン上がったらイメージのバージョンをあげればいいだけ
• ステートレスなのでやりやすい、イミュータブル/ディスポーザブル
• フローもシンプル
• パッケージ -> 出荷 -> 実行
• Docker の付随ファイルを少し管理するだけで良いので簡単
• 言語バージョンが違う場合でも Docker のパイプラインに載せればいいだけなので、管理がしやすい
• これだけでもいい感じだが、もっとやれることはないか？
• 例えば、言語、サービスごとにチームが管理、Docker コンテナは同じ
• テスト用に動いている環境は、ただのDockerなので、共通化できちゃう

Dev + Ops = DevOps

• Dev
• アプリそのもの
• 実行環境
• OS何使う、ライブラリ何使うかなど
• イミュータブル/ディスポーザブル
• Ops
• リソース、サービス間の管理
• コンテナが動く環境の管理
• どこに何を置くか
• ログ、監視など
• インフラを作るのだが、アプリとは分離
• 嬉しいところ
• DevOps のアジリティ、パイプラインを速く回す
• Dev のスペシャリストと Ops のスペシャリスト、それぞれででやる
• 重要な点 : インフラはいかなるアプリに依存しない、だからこそコンテナ

コンテナに適応したDevは

DevOpsに載せていきたいリストが、下記サイトにまとまっています。

• The 12-F app

ECS

• コンテナ管理を、あらゆるスケールで
• 何も準備しなくて良い
• 完全な状態
• どこに置くか選べて柔軟
• AWSの基盤連携
• ELB
• VPC
• CW

コンテナ管理

• コンテナが走るリソースが必要
• 変化するので管理する、追跡する
• リクエストを受け付ける
• 正確性と一貫性を担保する

Task Definishions (JSON)

• どういうイメージで、CPU、メモリ、どれぐらい使うか、ポートとかを選べる
• Task Difinisions を使ってコンテナインスタンスに指令する
• Dockerと連携してタスクを起動してくれる

スケジューラ

• 必要な情報を決める
• 決まった状態と今の状態wp比較して、実行する人
• スケジューラ -> マネージャー -> クラスタ (エージェントが1つずつ入ってる)
• ECS Agent は OSS

楽観的状態共有モデル

• スケジューラ
• クラスタが「何個空いてるかそれぞれが知ってる
• 空いてるところに起動しようとする
• 状態とって起動して、なのでコンフリクトは発生するが、先がちになり後のはリジェクト
• 起動したいもの起動して、ダメだったらもう一回
• ECS Service スケジューラ
• 立てっぱなしをモデルか
• 希望する状態を維持
• 定義を変えるとデプロイして入れ替えてくれる
• ELBとの連携もオプションdね可能
• ロングランニングアプリ
• min 50% max 100% にすると最小限でデプロイ
• min 100% max 200% にするとスピード早いがリソース食う

セグメント社の事例

• US スタートアップ
• データ集めて分析してマーケティング
• あるある、EC2インスタンスの設定が手作業、あるある
• Docker ベースにスイッチ、ECSを利用
• サービススケジューラが勝手にやるからデプロイが楽
• 管理が簡単になって開発に専念できるようになった
• 大きなベネフィットを得ることができた

最適化されたインフラ

• awslogs 経由で収集
• 出力先の選択肢が多い
• S3
• Stream
• Lambda
• Elasticserchservice
• Dockerがロギングドライバーの仕組みを持ってる
• awslogs が CW Logs にログを送ってくれる
• Log group サービスしてい
• Amazon ES 上の Kibana でログ検索できる、一元管理

Auto Scaling

• タスクの数を自動スケール
• CW Alarm から サービススケジューラにリクエストを送れる
• EC2 の AS と組み合わせて使うことができる
• メトリクスによるスケールが可能
• サービスごとのCPU、メモリ利用率
• クラスタごとのCPU、メモリ利用率
• 単純な計算式ではない
• クラスタごとのCPU、メモリ確保

SpotFleet

• Spot Instance は時価で起動、多くのケースで5割引で使える
• タイプや AZ によってバラバラだが、SpotFleet はそれを簡単に扱える
• 死んで足りなくなったら、次に安いやつを使える
• トータルのコスト削減

まとめ

• コンテナはDevOpsに取って自然
• Dev and Ops、組織にフィットしているか？
• ECS はとても簡単で柔軟。DevOps でも Dev + Ops でも。
• ぜひ本番でも！

感想

DevOps はある意味ふわふわした言葉でありますが「Dev」+「Ops」と考えると個人的にはすごくしっくり来ました。ECS などを上手く使いこなしながら、コストをかけずに実施できるようにすることが大切です。DevOps をやることが目的にならないように気をつけようと思いました。とにかく ECS がそこまで難しくなさそうな印象を受けたので、遊ぶところから始めてみたいと思います。